feat: add an interactive debugger to GnoVM #1563
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We provide here an embedded interactive debugger to let the user control and inspect its program at symbolic level, with the same features and commands as classical debuggers: gdb, lldb or delve. The debugger is enabled by setting the `-debug` flag in `gno run` command, which loads the target program and immediately shows a debugger prompt on the console: $ gno run -debug /tmp/my-program.gno Welcome to the Gnovm debugger. Type 'help' for list of commands. dbg> Providing `-debug-addr` flag allows to start a remote debugging session, and not interfer with the program stdin and stdout. For example, in a first terminal: $ gno run -debug-addr :4000 /tmp/my-program.gno Waiting for debugger client to connect at :4000 And in a second terminal, using a netcat like nc(1): $ nc localhost 4000 Welcome to the Gnovm debugger. Type 'help' for list of commands. dbg> The debugger works by intercepting each execution step at virtual machine level (each iteration within `Machine.Run` loop) to a callback, which in turns can provide a debugger command REPL or check if the execution can proceed to the next step, etc. This change request is still work-in-progress, as many debugger commands are not ready yet. Nevertheless, the general logic and structure is there. It is possible to `continue`, `stepi`, `detach`, etc and get a general feedback of the user experience and the impact on the code. Efforts are made to make this feature minimally intrusive in the actual VM, and not interfering when the debugger is not used. It is planned shortly after this PR is integrated to add the capacity to attach to an already running program, and to taylor the data format for existing debugging environments such as VScode, etc, as demand arises.
mvertes
requested review from
jaekwon,
piux2,
thehowl,
moul and
harry-hov
as code owners
mvertes
changed the title
go7066
reviewed
Feb 1, 2024
go7066
reviewed
Feb 1, 2024
go7066
reviewed
Feb 1, 2024
|
I have found some issues when computing the stack from a non func block (like I also found some issues when printing a global var. I would like also to set a test suite for the various debugger commands and in the various possible contexts such as the ones mentioned above. That requires a bit more work, maybe in a new PR (still pondering). |
harry-hov
approved these changes
Apr 25, 2024
Fix also list for sources comming from memory packages.
zivkovicmilos
approved these changes
Apr 29, 2024
The connection is now initiated of the debugger state machine, so the error can be processed from the start. It also allows slight simplifcations.
Also improve test coverage (now > 96% for debugger.go).
moul
reviewed
May 12, 2024
moul
approved these changes
May 12, 2024
thehowl
approved these changes
May 14, 2024
There was a problem hiding this comment.
Approving, sorry this took long.
I have a few grievances about the code duplication. I'd really prefer if we didn't have multiple implementations of essentially the same functionality in the same VM; as I think these create a maintainability problem. I'd look, if possible, to proceed unifying the code for injectLocOnPanic / debugUpdateLocation; likewise for debugEvalExpr. (Also because, fun fact, we already do have a "minimalistic parser"; see go doc gnolang.X).
If you can undertake efforts of unification, I'd really appreciate it. It may seem like shallow work; but I really believe that in the long-run, it will help us to avoid having to fix issues in three different expression parsers.
Same for injectLocOnPanic. We will need to have good line reporting anyway, with #1981 (ie. having stacktraces on GnoVM panics), so it's probably best if we end up with a single, good implementation.
That said, thank you for undertaking the effort and taking the time to address review comments.
Merging.
|
Yes @thehowl, I will now look at unifying common parts as you suggest. Thanks for your thorough review and useful suggestions. |
jefft0
pushed a commit
to jefft0/gno
that referenced
this pull request
May 15, 2024
 We provide here an embedded interactive debugger to let the user control and inspect its program at symbolic level, with the same features and commands as classical debuggers: gdb, lldb or delve. The debugger is enabled by setting the `-debug` flag in `gno run` command, which loads the target program and immediately shows a debugger prompt on the console: $ gno run -debug /tmp/my-program.gno Welcome to the Gnovm debugger. Type 'help' for list of commands. dbg> Providing `-debug-addr` flag allows to start a remote debugging session, and not interfer with the program stdin and stdout. For example, in a first terminal: $ gno run -debug-addr :4000 /tmp/my-program.gno Waiting for debugger client to connect at :4000 And in a second terminal, using a netcat like nc(1): $ nc localhost 4000 Welcome to the Gnovm debugger. Type 'help' for list of commands. dbg> The debugger works by intercepting each execution step at virtual machine level (each iteration within `Machine.Run` loop) to a callback, which in turns can provide a debugger command REPL or check if the execution can proceed to the next step, etc. The general logic and structure is there. It is possible to `continue`, `stepi`, `detach`, `print`, `stack`, etc and get a general feedback of the user experience and the impact on the code. Efforts are made to make this feature minimally intrusive in the actual VM, and not interfering when the debugger is not used. It is planned shortly after this PR is integrated to add the capacity to attach to an already running program, and to taylor the data format for existing debugging environments such as VScode, etc, as demand arises. Resolves gnolang/hackerspace#54 <!-- please provide a detailed description of the changes made in this pull request. --> <details><summary>Contributors' checklist...</summary> - [x] Added new tests, or not needed, or not feasible - [x] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [x] Updated the official documentation or not needed - [x] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [x] Added references to related issues and PRs - [x] Provided any useful hints for running manual tests - [ ] Added new benchmarks to [generated graphs](https://gnoland.github.io/benchmarks), if any. More info [here](https://github.com/gnolang/gno/blob/master/.benchmarks/README.md). </details> --------- Co-authored-by: Morgan <morgan@morganbaz.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We provide here an embedded interactive debugger to let the user control and inspect its program at symbolic level, with the same features and commands as classical debuggers: gdb, lldb or delve.
The debugger is enabled by setting the
-debugflag ingno runcommand, which loads the target program and immediately shows a debugger prompt on the console:Providing
-debug-addrflag allows to start a remote debugging session, and not interfer with the program stdin and stdout. For example, in a first terminal:And in a second terminal, using a netcat like nc(1):
The debugger works by intercepting each execution step at virtual machine level (each iteration within
Machine.Runloop) to a callback, which in turns can provide a debugger command REPL or check if the execution can proceed to the next step, etc.The general logic and structure is there. It is possible to
continue,stepi,detach,print,stack, etc and get a general feedback of the user experience and the impact on the code.Efforts are made to make this feature minimally intrusive in the actual VM, and not interfering when the debugger is not used.
It is planned shortly after this PR is integrated to add the capacity to attach to an already running program, and to taylor the data format for existing debugging environments such as VScode, etc, as demand arises.
Resolves gnolang/hackerspace#54
Contributors' checklist...
BREAKING CHANGE: xxxmessage was included in the description